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Abstract 

The  rapidly  evolving  technological  environment  presents  a  wealth  of  opportunities  to  the 
warfighter.  There  is  a  strong  need  to  be  able  to  systematically  identify,  develop,  and  integrate 
emerging  medical  technologies  into  mature,  functional,  and  cost-effective  systems  that  are 
capable  of  supporting  medical  readiness  and  meeting  operational  capability  requirements.  The 
NHRC  Medical  Engineering  Process  provides  a  comprehensive  process  of  checks  and  balances 
throughout  the  Research,  Development,  Test  and  Evaluation  cycle  for  field  medical  technologies. 
The  goals  of  this  program  include  facilitating  the  transition  of  research  and  development  (R&D) 
efforts  to  Department  of  Defense  programs  of  record,  decreasing  time  to  implementation, 
reducing  risk  of  application  failure,  increasing  return  on  investment  of  R&D  dollars,  and 
providing  the  warfighter  with  state-of-the-art,  reliable  tools  that  increase  survivability.  To  ensure 
the  technologies  produced  meet  immediate  and  long-term  requirement  capabilities,  NHRC  is 
maintaining  collaborative  relationships  with  customers  such  as  the  Navy  Medical  Chief 
Information  Officer,  the  Naval  Warfare  Development  Command,  the  Marine  Corps  Warfighting 
Lab,  and  the  Theater  Medical  Information  Program  Joint  Program  Office.  This  document  details 
the  design,  development,  and  initial  implementation  of  the  process  during  the  period  1  October 
2002  through  1  July  2005. 
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Background 

Because  technological  capabilities,  personnel  resources,  mission  needs,  and  security 
concerns  vary  with  the  nature  of  the  deployment  setting,  naval  forces  must  be  provided  with 
medical  devices  and  information  systems  that  fit  a  wide  variety  of  operating  conditions. 
Furthermore,  the  steady  development  of  cutting-edge  medical  technologies  requires  the  ability  to 
systematically  identify,  develop,  and  integrate  applicable  concepts  into  mature  prototype  systems 
that  functionally  and  cost-effectively  support  medical  readiness  and  meet  operational  capability 
requirements. 

The  Chief  of  Naval  Operations  has  published  his  vision  for  Navy’s  transformation,  Sea 
Power  21,  to  meet  the  challenges  of  the  twenty-first  century.  The  key  concepts  in  Sea  Power  21 
of  Sea  Basing,  Sea  Strike,  and  Sea  Shield  will  allow  the  Navy  to  meet  these  challenges.  (Clark, 
2002).  Furthermore,  the  new  Joint  Capabilities  Integration  and  Development  System  (JCIDS)  is 
a  top-down  process  designed  to  improve  coordination  with  government  departments  or  national 
agencies  resulting  in  capabilities  documents  tailored  to  each  phase  of  the  acquisition  process. 

The  system  includes  an  identification  process  to  determine  capabilities  gaps,  to  set  priorities,  and 
to  develop  joint  solutions  to  fill  the  capabilities  gaps.  (Chairman  of  the  Joint  Chiefs  of  Staff 
Instruction,  2005)  These  developments  have  highlighted  the  need  to  transform  Expeditionary 
Health  Service  Support  (EHSS)  capabilities  to  align  with  goals  of  Sea  Power  21  and  are  the 
driving  force  behind  the  Navy  transforming  its  historical  method  of  generating  requirements  into 
a  unified  and  streamlined  process. 

In  response,  the  Naval  Warfare  Development  Command  (NWDC)  has  been  tasked  to 
stand  up  a  Navy  Force  Health  Protection  21  Combat  Development  Process  (NFHP-21  CDP). 

This  process  will  identify  and  assess  EHSS  operational  requirements  and  capabilities.  The  new 
process,  under  development  at  NWDC,  is  designed  to  align  with  and  to  support  the  JCIDS 
program.  As  such,  the  NFHP-2 1  CDP  includes  four  complementary  phases  to  the  JCIDS 
analytical  approach.  During  the  Force  Capability  Development  phase,  capability  gaps  are 
identified  and  a  Universal  Needs  Statement  (UNS)  is  developed.  When  the  completed  UNS  is 
entered  into  the  NFHP-21  Combat  Tracking  System,  the  Requirement  Development  phase 
begins.  As  part  of  this  phase,  the  UNS  is  reviewed  and  sent  to  the  Doctrine,  Organization, 
Training,  Materiel,  Leadership,  Personnel  and  Facilities  (DOTMLPF)  working  group  for  analysis 
and  for  their  recommendation  of  a  materiel  or  nonmateriel  solution.  During  the  Prioritization  and 
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Resourcing  phase,  the  previously  identified  requirements  are  determined  to  be  critical  or  not 
critical  for  the  fleet/force  mission.  Finally,  during  the  Capability  Fielding  and  Transition  phase, 
the  acquisition  process  is  initiated  to  field  the  new  capability.  Non-materiel  solutions  will  be 
handled  through  the  DOTMLPF  process  in  a  similar  way,  ending  with  Fielding  and  Transition. 

Application 

The  Naval  Health  Research  Center  (NHRC)  Naval  Medical  Engineering  Process 
(NMEP),  working  in  conjunction  with  the  later  three  phases  of  NFHP-21  CDP,  is  intended  to 
gather  operational  requirements,  to  assess  candidate  technological  solutions  for  those 
requirements,  and  to  design  and  to  develop  technological  solutions  as  appropriate.  The  process 
includes  the  test  and  evaluation  (T&E)  of  both  prototypes  and  commercial-off-the-shelf 
technology  intended  to  support  deployed  medical  caregivers  as  they  provide  combat  casualty 
care  and  conduct  medical  surveillance.  The  NMEP  provides  a  comprehensive  checks  and 
balances  process  throughout  the  RDT&E  cycle  for  field  medical  technologies. 

There  are  four  phases  in  the  NMEP:  Technology  Watch  (TW),  Quality  Assurance  (QA), 
Verification  and  Validation  (V&V),  and  Field  Test  and  Evaluation  (FT&E).  During  the  TW 
phase  requirements  are  validated  and  expectations  are  set  for  development.  The  QA  phase 
incorporates  steps  to  closely  monitor  development  against  those  validated  requirements.  During 
the  V&V  phase,  a  series  of  rigorous  tests  are  conducted  to  demonstrate  that  the  product  or 
system  has  been  built  according  to  specified  functionality.  Military  Utility  Assessments  (MU As) 
and  Military  Feasibility  Assessments  (MFAs)  are  conducted  during  the  FT&E  phase  in 
operational  and  exercise  settings  to  ensure  that  the  new  product  or  system  meets  desired 
operational  capability  requirements,  and  does  so  in  a  way  that  is  practical  and  cost-effective  from 
an  operational  mission  perspective. 

NMEP  goals  include  the  following: 

1.  Facilitate  transitioning  research  and  development  (R&D)  efforts  to  the  Department  of 
Defense  (DoD)  by  providing  high  quality  assurance. 

2.  Reduce  time  to  implementation  by  validating  confidence  in  applications  before  taking 
final  steps  to  transition. 

3.  Reduce  risk  of  application  failure  prior  to  deployment  in  operational  settings. 
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4.  Reduce  exposure  to  financial  loss  due  to  application  insufficiencies. 

5.  Increase  return  on  investment  of  R&D  dollars. 

6.  Increase  efficiency  and  customer  confidence  in  the  R&D  process. 

7.  Provide  the  warfighter  with  state-of-the-art,  reliable  tools  that  increase  survivability. 

To  mitigate  the  potential  gap  between  RDT&E  funding  and  funding  for  continued 
sustainment  through  the  Program  Objective  Memorandum  and  budget  process,  as  soon  as  a 
candidate  product  or  system  is  selected  for  QA,  V&V,  or  FT&E,  a  technology  transition  plan 
(TTP)  is  initiated.  A  sample  TTP  can  be  found  in  the  Appendix.  The  TTP  is  modeled  after  the 
Office  of  Naval  Research  (ONR)  Future  Naval  Capability  Technology  Transition  Agreement. 
Initiating  a  TTP  assists  the  research  community  in  identifying  transition  partners,  understanding 
their  needs  and  processes,  and  actively  working  to  identify  transition  opportunities  in  terms  of 
their  schedules  and  budgetary  constraints.  An  additional  benefit  of  the  TTP  process  is  that 
products  or  systems  with  no  viable  transition  partners  identified  prior  to  entering  the  FT&E 
phase  can  be  targeted  by  leadership  in  the  research  community  for  discontinuation. 

Another  approach  designed  to  ensure  that  a  candidate  project  meets  the  required  needs  is 
the  use  of  configuration  management,  a  discipline  that  applies  technical  and  administrative 
direction  and  surveillance  over  the  life  cycle  of  items  to  accomplish  the  following:  (1)  identify 
and  document  the  functional  and  physical  characteristics  of  configuration  items;  (2)  control 
changes  to  configuration  items  and  their  related  documentation;  (3)  record  and  report 
information  needed  to  manage  configuration  items  effectively,  including  the  status  of  proposed 
changes  and  implementation  status  of  approved  changes;  and  (4)  audit  configuration  items  to 
verify  conformance  to  specifications,  drawings,  interface  control  documents,  and  other 
contractual  requirements. 

Because  products  and  systems  are  increasing  in  complexity,  to  the  point  that  no 
individual  has  the  ability  to  comprehend  the  whole  or  the  technical  depth  to  understand  all  of  its 
parts,  management  of  technological  information  is  increasingly  important.  Technologies  come 
and  go  at  a  rapid  pace,  increasing  the  number  of  solution  options  to  be  evaluated  for  any  product 
or  capability.  Meanwhile,  the  immediacy  of  the  need  to  field  an  operational  capability  has  made 
it  essential  that  the  process  times  in  each  of  the  NMEP  phases  be  minimized.  Budgets  are 
declining,  highlighting  the  need  for  effective  strategies  that  include  reuse  of  technologies, 
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components,  decisions,  and  tests.  The  ability  to  design  the  “right  thing,  right  the  first  time”  is 
paramount.  This  implies  that  the  customer  must  be  fully  engaged  at  all  stages  of  the  NMEP. 
Finally,  naval  customers  expect  that  developers  follow  a  comprehensive  product  development 
process  that  yields  100%  verification  that  their  requirements  have  been  implemented 
successfully.  For  the  reasons  listed  above,  the  NMEP  employs  the  Telelogic  requirements 
management  tool,  Dynamic  Object  Oriented  Requirements  System  (DOORS),  throughout  all 
process  phases  (Telelogic  North  America  Inc.,  Irvine,  CA). 

DOORS  allows  effective  management  and  control  during  product  development.  Changes 
inevitably  occur  as  solutions  are  implemented,  often  with  little  or  no  analysis  of  the  effect  of 
those  changes.  DOORS  provides  the  analysis  tools  to  reveal  which  requirements  will  be  affected 
by  a  change.  Requirements  documents  are  often  uncontrolled  with  changes  occurring  throughout 
the  entire  life  cycle.  A  Change  Proposal  System  within  DOORS  controls  those  changes  and 
relates  any  changes  back  to  cost  and  schedule  so  that  a  clear  view  of  product  status  is  provided. 

Technology  Watch  (TW) 

The  TW  phase  of  the  NMEP  is  designed  to  review  the  plethora  of  new  technologies 
produced  by  the  government  and  industry,  and  to  identify  and  prioritize  the  most  promising 
candidates  against  validated  requirements,  such  as  the  NFHP-21  CSDP.  Additionally,  it  is  in  this 
phase  that  a  gap  analysis  is  performed  and  future  R&D  needs  identified.  The  objective  of  this 
part  of  the  process  has  been  to  develop  a  concept  of  operations  (CONOPS)  for  NHRC  to  work 
with  NWDC  to  support  an  approach  for  developing,  tracking,  and  approving  medical 
requirements  as  well  as  to  provide  research  support  for  evaluation  and/or  validation  of  any 
prospective  technological  solutions.  It  is  important  to  note  that  NHRC  and  the  NMEP  do  not 
validate  or  own  the  requirements.  Such  requirements  belong  to  programs  like  the  Naval  Air 
Systems  Command,  Naval  Sea  Systems  Command,  and  the  TMIP,  which  in  turn  meet  the 
requirements  of  JCIDS.  Developing  the  CONOPS  includes  design  of  an  automated  system  to 
track  processing  of  prospective  medical  requirements  coming  to  NWDC  and  conducting  a 
technology  survey  using  search  engines  such  as  Google  and  research  to  evaluate  “best- fit” 
technologies  for  new  medical  requirements,  such  as  shipboard  surgical  systems  or  field  medical 
surveillance. 
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Quality  Assurance(QA) 

The  focus  of  this  work  will  address  system  scalability,  reliability,  and  security  elements 
of  prototype  information  technology  (IT)  solutions.  Quality  assurance  efforts  ensure  that 
hardware  and  software  meet  standards  for  security,  data  handling  (i.e.,  Health  Insurance 
Portability  and  Accountability  Act  [HIPAA]),  and  communications  (e.g.,  IT-21,  the  Navy 
Information  Technology  for  the  21st  Century  program).  While  both  military  and  industrial 
standards  exist  to  verify  such  security,  the  scope  of  such  efforts  varies  according  to  the  range  of 
operational  application.  Continental  United  States  versus  in-theater  employment,  or  joint  service 
system  integration,  for  example,  can  expand  the  extent  of  security  analysis  tasks. 

There  are  two  main  objectives  to  this  stage.  The  first  objective  is  to  provide  quality 
assurance  support  for  the  NHRC  R&D  Information  Management/Information  Technology 
Process.  This  iterative  process  involves  testing  medical  software  applications  that  are  currently 
under  development.  Black  box  testing  and  white  box  testing  are  used  in  this  phase.  Black  box 
testing  purposefully  takes  place  without  any  knowledge  of  the  internal  design  of  the  code  and 
relies  on  behavioral  tests  developed  from  functional  and  compliance  requirements.  The  test 
engineer  proceeds  through  test  cases  (scripts)  that  contain  detailed  steps  for  testing  each 
requirement.  A  comparison  is  documented  between  the  expected  test  results  and  the  observed 
actual  results. 

During  white  box  testing,  the  internal  logic  of  an  application’s  code  is  considered.  Tests 
include  the  analysis  of  source  code,  conformity  to  requirements,  and  high-level  design.  Test 
cases  are  designed  with  detailed  steps  that  test  each  path  in  the  code,  as  well  as  describe  the 
corresponding  expected  results.  A  comparison  is  documented  between  the  expected  test  results 
and  the  observed  actual  results.  Documenting  the  results  of  the  NHRC  R&D  IM/IT  Process,  and 
communicating  this  information  in  DoD  format  meets  the  objective  of  supporting  more-effective 
medical  decision  making  and  may  lead  to  improved  procedures  for  treating  combat  casualties. 

Verification  and  Validation  (V&  V) 

The  V&V  process  includes  verification  and  validation  studies  on  applications  submitted 
via  third  parties.  Steps  in  this  phase  include  gleaning  functional  requirements  from  the 
application  documentation  and  available  materials,  including  compliance  documentation;  gap 
analysis  to  determine  missing  functional  requirements  and  identify  unnecessary  functional 


requirements;  preparing  test  cases  detailing  steps  for  testing  each  functional  requirement; 
executing  the  test  scripts;  and  recording  test  results.  A  Report  of  Findings  is  generated  in  this 
phase  detailing  the  conclusions  of  the  V&V  team,  stating  the  methodology  used  to  arrive  at  these 
conclusions,  and  providing  the  results  of  each  test  case  in  summarized  format.  This  report  is  the 
basis  upon  which  the  product  or  system  is  deemed  acceptable  for  further  consideration  by  naval 
medical  decision  makers.  During  this  part  of  the  process,  medical  technologies  undergo 
systematic,  evidence-based  validation  to  corroborate  (or  disprove)  the  performance  claims  of 
their  developers  and  to  prepare  them  for  field  testing.  The  verification  takes  place  within  an 
established  framework  that  incorporates  industry  standards  and  DoD  practices. 

Four  deliverables  are  produced  for  each  product  or  system  tested:  Installation  and  Initial 
Assessment,  Requirements  Specification,  V&V  Plan,  and  a  Report  of  Findings.  The  Report  of 
Findings  includes  one  of  four  possible  recommendations:  integrate  the  application  into  a  suite  for 
field  testing,  approve  the  application  for  general  use,  reject  the  application  for  defects  in 
workmanship  or  quality,  or  accredit  the  application  for  transition.  In  an  effort  to  keep  the  work 
independent  and  objective,  V&V  team  members  cannot  participate  in  technological 
development. 

Field  Test  and  Evaluation  (FT&E) 

The  function  of  the  FT&E  phase  is  to  answer  the  question:  “Was  the  correct  thing  built?” 
This  is  the  part  of  the  process  that  determines  the  utility  of  an  application  to  the  Navy  and  Marine 
Corps,  which  must  be  done  by  active  military  personnel  in  the  field  or  in  an  environment  that 
replicates  the  field  anticipated  operational  setting  in  which  the  technology  will  be  employed. 

The  FT&E  team  recommends  venues;  identifies  requirements  for  approved  venues; 
implements  upgrades  at  long-term  venues;  communicates  the  requirements  and  schedules  to  all 
third  parties;  coordinates  participation  at  the  approved  venues;  surveys  MILPERS  who 
participate  at  the  venues  for  feedback  on  the  viability,  usability,  and  utility  of  the  applications; 
collects  and  coordinates  all  After  Action  Reports  tracking  to  resolution;  executes  exit  strategies 
(i.e.,  collecting  all  hardware  and  software  previously  deployed,  circulating  surveys);  and 
produces  an  MUA  and  MFA  with  regard  to  the  utility  of  applications  tested  in  the  field. 

Lessons  learned  in  the  QA,  V&V,  and  FT&E  phases  are  fed  back  to  the 
Requirements/Technology  Watch  phase  as  potential  new  requirements,  enhancement  requests 
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and  Technical  Assistance  Requests.  The  identified  user  feedback  is  provided  to  the  product-line 
developers,  thus  ensuring  the  systems  developed  meet  the  users’  requirements.  FT&E  is  the 
NMEP  phase  that  provides  the  interface  between  the  integrated  medical  technology  production 
line  and  the  user  base  by  coordinating  limited  planned  deployment  of  the  integrated  systems  and 
T&E  of  such  systems. 

Progress  through  1  July  2005 

Examples  of  products  that  have  gone  through  one  or  more  of  the  NMEP  phases: 

1.  Field  Medical  Companion  (FMC):  Delivers  immediate,  critical  information  to  first 
responders  and  warfighters  in  far-forward  and  remote  environments. 

a.  May  through  September  2004  -  FT&E  of  the  consolidated  FMC  containing 
both  Medical  Information  Modules  and  Patient  Data  Capture  on  one  handheld 
device. 

2.  Medical  Data  Surveillance  System  (MDSS):  Designed  and  developed  as  a  Web- 
enabled  system  for  the  medical  surveillance  of  Navy  and  Marine  Corps  deployed 
forces.  The  primary  objective  of  the  system  was  to  rapidly  detect  medical  threats 
through  the  analysis  of  routinely  collected  patient  data. 

a.  2003  -  T&E  of  MDSS  at  Navy  and  Marine  Corps  medical  treatment  facilities. 
(Melcer,  Bohannan,  Burr,  Leap,  Reed,  &  Jeschonek,  2003). 

3.  Shipboard  Medical  Administrative  Readiness  Tool  (SMART):  This  prototype  Web- 
based  application  was  designed  to  provide  tactical  and  medical  command  and  control 
assessments  of  the  medical  readiness  of  the  force. 

a.  March  2004  -  Completed  testing  on  SMART  prototype 

b.  March  2004  -  Issued  draft  final  report  on  SMART,  including  an  analysis  of 
subject  matter  expert  opinion  and  functionality  information. 
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4.  Telemedicine:  This  effort  evaluated  the  use  of  telecommunications  technologies  to 
assist  in  delivering  health  care  to  remote  or  distant  treatment  sites,  such  as  aboard 
ship. 

a.  2004  -  Assessment  of  interoperability  (Reed,  Burr,  &  Melcer,  2004) 

b.  2003  -  Evaluation  of  telemedicine  satisfaction  among  Navy  radiologists 
(Bohannan,  Strychacz,  and  Melcer,  2003) 

c.  2002  -  Current  research  in  and  future  directions  of  Navy  telemedicine  (Reed, 
Burr,  &  Melcer,  2002) 

d.  2002  -  Retrospective  evaluation  of  the  development  of  a  telemedicine 
network  in  a  military  setting  (Melcer,  Crann,  Hunsaker,  Deniston,  &  Caola, 
2002). 

e.  2002  -  Prospective  evaluation  of  ENT  telemedicine  in  remote  military 
populations  seeking  specialty  care  (Melcer,  Hunsaker,  Crann,  Caola,  & 
Deniston,  2002) 

5.  Tactical  Medical  Logistics  Planning  Tool  (TML+):  TML+  includes  a  simulation  tool 
that  models  the  patient  flow  from  the  point  of  injury  through  more-definitive  care, 
and  a  research  tool  that  supports  systems  analysis,  operational  risk  assessment,  and 
field  medical  services  planning. 

a.  May  2004  -  Initial  TML+  testing 

b.  May  2004  -  Review  of  available  materials  for  TML+  and  plan  for  user 
training  and  new  surveys  for  evaluation  of  the  software  complete. 

c.  April  2004  -  Review  of  current  version  of  the  TML+  User’s  Manual,  and  the 
Methodology  Manual. 

6.  Tactical  Medical  Coordination  System  (TacMedCS):  Non-physical-contact  data 
transmission  and  storage  media  are  used  to  uplink  casualty  information  to  a  theater 
information  network,  providing  enhanced  situational  awareness  and  increased 
casualty  accountability 

a.  April  through  July  2004  -  Participated  with  the  Marine  Corps  Warfighting 
Lab  (MCWL)  in  the  test  and  evaluation  of  TacMedCS. 
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7.  Humanitarian  Aid  Projects: 

a.  September  2004  -  Integration  and  T&E  of  a  suite  of  tools  to  take  to  Terminal 
Fury  2004  in  November  2004 

b.  June  2004  -  Integration  and  T&E  of  a  suite  of  tools  to  take  to  Vanguard  2004 

c.  March  2004  through  May  2004  -  Support  data  collection  and  evaluation  for 
Cobra  Gold  ’04  exercise 


Benefits 

NHRC  has  applied  the  rigor  of  this  engineering  process,  which  incorporates  QA  in 
support  of  technology  research  and  development  rather  than  generating  new  products,  to  the 
product  pipeline  and  increased  the  quality  of  its  R&D  and  the  products  it  transitions.  NHRC  is 
establishing  relationships  with  customers  and  transition  partners  such  as  the  Navy  Medical  Chief 
Information  Officer,  NWDC,  MCWL,  and  the  TMIP-J  Program  Office  to  ensure  that  the 
products  and  systems  produced  meet  the  immediate  and  long-term  requirement  capabilities. 

The  NMEP  will  guarantee  that  devices  work  within  austere  conditions  and  are 
interoperable  with  existing  devices.  In  the  future,  the  process  will  expand  to  continue  to  reduce 
Science  and  Technology  (S&T)  risk  through  minimizing  duplicative  effort,  maximizing  cost 
avoidance,  and  testing  capabilities  within  an  expeditionary  environment.  This  process  will 
provide  acquisition  agencies  with  the  data  needed  to  make  informed  acquisition  or  development 
decisions  and  to  select  from  multiple  systems  considered  for  Navy  or  Marine  Corps  use. 

In  its  initial  instantiation,  the  NMEP  process  has  reduced  cost  per  project,  improved 
quality  across  all  projects,  and  increased  customer  confidence  in  the  R&D  projects  contemplated 
for  transition  to  the  appropriate  program  of  record.  The  NMEP  has  supported  NWDC’s  response 
to  JCIDS  requirements  and  provided  the  flexibility  to  adapt  as  requirements  are  updated  and 
modified. 
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Appendix 


Naval  Health  Research  Center 

TEMPLATE  FOR  MEMORANDUM  OF  AGREEMENT  (MO A) 

Memorandum  of  Agreement  Between  Naval  Health  Research  Center  and 
[Target  Acquisition  Program]  for  the  S&T  Transition  of 
[Title  of  transitioning  technology] 


1.  This  Memorandum  of  Agreement  (MO  A)  between  the  Naval  Health  Research  Center  (NHRC) 
and  [Target  Acquisition  Program]  program  defines  the  path  of  transition  for  [number]  of  R&D 
products;  (1)  [technology  1],  and  (2)  [technology  2],  etc.  -  can  be  expanded  to  list  as  many 
technologies  as  needed],  NHRC  performs  a  [multi-]year  technology  development  program  that 
will  result  in  these  tools  and  strategies  that  the  [Target  Acquisition  Program]  program  will 
incorporate  upon  successful  demonstration.  [Depending  on  project,  may  need  to  include  brief 
description  of  major  program  objectives,  current  phase  of  acquisition  life  cycle,  and  project 
initial  operational  capability  date.] 

[Information  in  the  next  four  sections  to  be  provided  by  the  Program  Office] 

2.  [Name  of  Target  Acquisition  Program]  Program  Manager:  Name  (Command,  code,  etc.) 

Program  Manager/Project  Officer.  Program  manager  and  individual  in  program  office 
responsible  for  day-to-day  management  with  contact  information. 

3.  Acquisition  Program  Technology  Need: 


Brief  description  of  the  benefit  that  this  technology  will  bring  to  the  acquisition  program,  or  need 
satisfied.  Where  possible,  relate  benefit  to  the  Operational  Requirements  Document  (which  is 
being  phased  out  and  replaced  by  a  similar  document  called  the  Capabilities  Development 
Document  [CDD])  and  Key  Performance  Parameters  (KPP).  Desired  user  capabilities,  expressed 
in  terms  of  KPPs  and  other  parameters,  should  be  defined  in  terms  of  the  following: 

•  Quantifiable  metrics  (e.g.,  speed,  lethality)  of  performance  to  meet  mission  requirements 
affordably;  and 

•  The  full  range  of  operational  requirements  (reliability,  effectiveness,  logistics  footprint, 
supportability  criteria,  etc.)  to  sustain  the  mission  over  the  long  term. 

In  their  initial  stages,  the  KPPs  are  general,  broadly  defined  and  become  more  specifically 
defined  as  a  program  matures.  Include  needed  dates  for  specific  capabilities.  The  Program  Office 
should  provide  an  opinion  of  technology  maturity  at  transition.  This  may  be  done  by  risk  level  or 
by  using  the  following  Technology  Readiness  Level  (TRL)  nomenclature.  TRLs  are  a  measure  of 
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technical  maturity.  They  do  not  discuss  the  probability  of  occurrence  (i.e.,  the  likelihood  of 
attaining  required  maturity)  or  the  impact  of  not  achieving  technology  maturity. 


Readiness  Level 

Description 

1 .  Basic  principles  observed  and  reported. 

Lowest  level  of  technology  readiness.  Scientific 
research  begins  to  be  translated  into  applied 
research  and  development.  Examples  might 
include  paper  studies  of  a  technology's  basic 
properties. 

2.  Technology  concept  and/or  application 
formulated. 

Invention  begins.  Once  basic  principles  are 
observed,  practical  applications  can  be  invented. 
Applications  are  speculative  and  there  may  be 
no  proof  or  detailed  analysis  to  support  the 
assumptions.  Examples  are  limited  to  analytic 
studies. 

3.  Analytical  and  experimental  critical  function 
and/or  characteristic  proof  of  concept. 

Active  research  and  development  is  initiated. 

This  includes  analytical  studies  and  laboratory 
studies  to  physically  validate  analytical 
predictions  of  separate  elements  of  the 
technology.  Examples  include  components  that 
are  not  yet  integrated  or  representative. 

4.  Component  and/or  breadboard  validation  in 
laboratory  environment. 

Basic  technological  components  are  integrated 
to  establish  that  they  will  work  together.  This  is 
relatively  "low  fidelity"  compared  to  the 
eventual  system.  Examples  include  integration 
of  "ad  hoc"  hardware  in  the  laboratory. 

5.  Component  and/or  breadboard  validation  in 
relevant  environment. 

Fidelity  of  breadboard  technology  increases 
significantly.  The  basic  technological 
components  are  integrated  with  reasonably 
realistic  supporting  elements  so  they  can  be 
tested  in  a  simulated  environment.  Examples 
include  "high  fidelity"  laboratory  integration  of 
components. 

6.  System/subsystem  model  or  prototype 
demonstration  in  a  relevant  environment. 

Representative  model  or  prototype  system, 
which  is  well  beyond  that  of  TRL  5,  is  tested  in 
a  relevant  environment.  Represents  a  major  step 
up  in  a  technology's  demonstrated  readiness. 
Examples  include  testing  a  prototype  in  a  high- 
fidelity  laboratory  environment  or  in  simulated 
operational  environment. 

7.  System  prototype  demonstration  in  an 
operational  environment. 

Prototype  near,  or  at,  planned  operational 
system.  Represents  a  major  step  up  from  TRL  6, 
requiring  demonstration  of  an  actual  system 
prototype  in  an  operational  environment  such  as 
an  aircraft,  vehicle,  or  space.  Examples  include 
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testing  the  prototype  in  a  test  bed  aircraft. 


8.  Actual  system  completed  and  qualified 
through  test  and  demonstration. 

Technology  has  been  proven  to  work  in  its  final 
form  and  under  expected  conditions.  In  almost 
all  cases,  this  TRL  represents  the  end  of  true 
system  development.  Examples  include 
developmental  test  and  evaluation  of  the  system 
in  its  intended  weapon  system  to  determine  if  it 
meets  design  specifications. 

9.  Actual  system  proven  through  successful 
mission  operations. 

Actual  application  of  the  technology  in  its  final 
form  and  under  mission  conditions,  such  as 
those  encountered  in  operational  test  and 
evaluation.  Examples  include  using  the  system 
under  operational  mission  conditions. 

Definitions: 

Breadboard:  Integrated  components  that  provide  a  representation  of  a  system/subsystem  and 
which  can  be  used  to  determine  concept  feasibility  and  to  develop  technical  data.  Typically 
configured  for  laboratory  use  to  demonstrate  the  technical  principles  of  immediate  interest.  May 
resemble  final  system/subsystem  in  function  only. 

High  Fidelity:  Addresses  form,  fit,  and  function.  High  fidelity  laboratory  environment  would 
involve  testing  with  equipment  that  can  simulate  and  validate  all  system  specifications  within  a 
laboratory  setting. 

Low  Fidelity:  A  representative  of  the  component  or  system  that  has  limited  ability  to  provide 
anything  but  first  order  information  about  the  end  product.  Low  fidelity  assessments  are  used  to 
provide  trend  analysis. 

Model:  A  reduced  scale,  functional  form  of  a  system,  near  or  at  operational  specification. 

Models  will  be  sufficiently  hardened  to  allow  demonstration  of  the  technical  and  operational 
capabilities  required  of  the  final  system. 

Operational  Environment:  Environment  that  addresses  all  of  the  operational  requirements  and 
specifications  required  of  the  final  system,  to  include  platform/packaging. 

Prototype:  The  first  early  representation  of  the  system  that  offers  the  expected  functionality  and 
performance  expected  of  the  final  implementation.  Prototypes  will  be  sufficiently  hardened  to 
allow  demonstration  of  the  technical  and  operational  capabilities  required  of  the  final  system. 
Relevant  Environment:  Testing  environment  that  simulates  the  key  aspects  of  the  operational 
environment. 

Simulated  Operational  Environment:  Environment  that  can  simulate  all  of  the  operational 
requirements  and  specifications  required  of  the  final  system  or  a  simulated  environment  that 
allows  for  testing  of  a  virtual  prototype  to  determine  whether  it  meets  the  operational  retirements 
and  specifications  of  the  final  system. 

4.  Transition  Plan.  [Also  called  Integration  Strategy] 

Describe  the  process  for  integrating  the  technology  into  the  acquisition  program.  Include 
elements  of  acquisition  strategy  -  evolutionary  acquisition,  block  upgrade,  etc.,  as  well  as 
required  contractor-to-contractor  agreements.  Include  the  Program  Elements  (PE’s)  that 
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acquisition  intends  to  fund  the  transition  and  annual  PE  funding  levels  committed  to  the 
transition  program.  Also  include  the  associated  transition  FY. 

Transition:  FY-00  Completion 
[Target  Acquisition  Program] 

R&D  [Funding  Information] 

Funds  Allocated  to  Transition  ($M) 


FY02 

FY03 

FY04 

FY05 

FY06 

FY07 

Total 

Program 

1.00 

[Information  in  the  next  six  sections  to  be  provided  by  the  S&T  Activity] 

5.  Description  of  Technology/Capability: 

Description  of  Technology  or  Capability  to  be  Delivered.  Brief  description  of  what  the  S&T 
activity  intends  to  develop  for  transition  to  the  acquisition  program.  Include  capability  delivery 
dates. 

[The  ONR  example  included  this  funding  table] 

S&T  Funding  ($M) 


PE 

Project 

FY02 

FY03 

FY04 

FY05 

FY06 

FY07 

6.  NHRC  Technology  Manager:  Name,  [Project  Name]  Project  Manager,  NHRC 

7.  Current  Status. 

Status  Summary.  Summarize  current  state  of  development.  Identify  primary  areas  where 
additional  development  is  required.  Technology  Readiness  Levels  are  a  measure  of  technical 
maturity  and  can  be  used  to  assess  readiness  to  transition. 

1 .  Provide  estimate  of  current  TRL  (use  previously  included  table  of  levels.) 

2.  Risk  Analysis.  Major  areas  of  risk,  prioritized,  with  planned  mitigation  activities 
include  technical  (e.g.,  producibility,  affordability,  sustainability)  cost,  and  schedule 
risks. 


8.  Technology  Development  Strategy: 
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Outline  approach  planned.  Efforts  required  beyond  those  currently  underway,  integration  plans  if 
multiple  projects  are  planned.  Planned  ATD  or  ACTD  developments,  if  applicable. 

9.  Key  Measures  of  Transition  Readiness 


Product 

Current 

Interim 

Final  Objective 

Identify  the  key  parameters  or  attributes  that  will  be  used  to  measure  whether  or  not  the 
technology  development  effort  is  proceeding  appropriately.  Include  parameter  to  be  tracked, 
current  state,  interim  progress  estimates,  and  final  objective. 

10.  Program  Plan 


Tasks 


FY02  FY03  FY04  FY05  FY06  FY07 


Program  Manager, 

[Name  of  Acquisition  Program] 


[Name  of  Project] 
Technical  Manager,  NHRC 


18 


Useful  Acronyms 

ACTD:  Advanced  Concept  Technology  Demonstrations 
ATD:  Advanced  Technology  Demonstrations 
CDD:  Capabilities  Development  Document 
FY:  Fiscal  Year 

KPP:  Key  Performance  Parameters 
MOA:  Memorandum  of  Agreement 
NHRC:  Naval  Health  Research  Center 
ORD:  Operational  Requirements  Document 
PE(s):  Program  Element(s) 

R&D:  Research  and  Development 
RDT&E:  Research,  Development,  Test  and  Evaluation 
TMIP-J:  Theater  Medical  Information  Program  -  Joint 
TRL:  Technology  Readiness  Level 


REPORT  DOCUMENTATION  PAGE 

The  public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching 
existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this 
burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  the  burden,  to  Washington  Headquarters  Services, 
Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,  Respondents  should  be  aware  that 
notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  any  penalty  for  failing  to  comply  with  a  collection  of  information  if  it  does  not  display  a 
currently  valid  OMB  Control  number.  PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. _ 
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